home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP112992.ARJ / 11-29-92.TPC
Text File  |  1992-11-29  |  71KB  |  2,176 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       11-23-92 05:23:30
  6. From       Trevor Carlsen
  7. To         Frank Masingill
  8. Subject    Reading a number from com
  9.  
  10.  
  11.  
  12.  FM> Maybe THAT'S the answer.  I never upgraded from 5.5  I don't
  13.  FM> recall the program now but do recall capturing it.  I
  14.  FM> usually send such code to a subdirectory of some category I
  15.  FM> think it fits and then I shell out of my editor to test it.
  16.  
  17. TP55 should have exactly the same result here.  What commandline did you use
  18. that did not work?
  19.  
  20. TeeCee
  21.  
  22. --- TC-ED   v2.01  
  23.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  24.  * Tossed by SFToss/286 v1.02a on 92/11/24  09:38:08
  25.  
  26. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  27.  
  28. Conference 4
  29. Date       11-23-92 13:37:35
  30. From       Trevor Carlsen
  31. To         Kelly Small
  32. Subject    Array of Pointers
  33.  
  34.  
  35.  
  36.  TC> It is probably overkill to use an array of pointers for this
  37.  TC> as it would u almost 50% as much memory again.  Better may
  38.  TC> be to split the strings into arrays with very little memory
  39.  TC> penalty.
  40.  
  41.  KS> This what I tried, but ran into problems with routines such
  42.  KS> quicksort.
  43.  
  44. Done as I suggested it would not be a problem.  
  45.  
  46. BTW my estimate of an array of pointers method taking up almost as much as
  47. 50% extra memory would be way off the mark.  Assuming you are using TP6 every
  48. string[8] allocated would take 20 bytes - 16 for the string and 4 for the
  49. pointer. Makes an array of pointers even less attractive in this case.
  50.  
  51. TeeCee
  52.  
  53. --- TC-ED   v2.01  
  54.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  55.  * Tossed by SFToss/286 v1.02a on 92/11/24  09:38:09
  56.  
  57. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  58.  
  59. Conference 4
  60. Date       11-23-92 13:16:01
  61. From       Trevor Carlsen
  62. To         Bob Barberio
  63. Subject    JUSTIFYING TEXT
  64.  
  65.  
  66.  
  67.  BB> ... I have to write a program that reads a file as input and
  68.  BB> prints the file right and left justifying the text.  It must
  69.  BB> print 60 characters per line.
  70.  
  71. Here is a program that demonstrates both word wrap and justifying.  The wrap
  72. routine was posted here some weeks back and the justifying has been added. 
  73.  
  74. I'll leave it to you to add your own reading the file routines.
  75.  
  76. var
  77.   S : string;
  78.  
  79. function Wrap(var st: string; maxlen: byte; justify: boolean): string;
  80.   { returns a string of no more than maxlen characters with the last   }
  81.   { character being the last space before maxlen. On return st now has }
  82.   { the remaining characters left after the wrapping.                  }
  83.   const
  84.     space = #32;
  85.   var 
  86.     len      : byte absolute st;
  87.     x,
  88.     oldlen,
  89.     newlen   : byte;
  90.  
  91.   function JustifiedStr(s: string; max: byte): string;
  92.  
  93.     { Justifies string s left and right to length max. If there is more }
  94.     { than one trailing space, only the right most space is deleted. The}
  95.     { remaining spaces are considered "hard".  #255 is used as the char }
  96.     { used for padding purposes. This will enable easy removal in any   }
  97.     { editor routine.                                                   }
  98.  
  99.     const
  100.       softSpace = #255;
  101.     var
  102.       jstr      : string;
  103.       len       : byte absolute jstr;
  104.     begin
  105.       jstr := s;
  106.       while (jstr[1] = space) and (len > 0) do   { delete all leading spaces }
  107.  
  108.         delete(jstr,1,1);
  109.       if jstr[len] = space then
  110.         dec(len);                                { Get rid of trailing space }
  111.  
  112.       if not ((len = max) or (len = 0)) then begin
  113.         x := pos('.',jstr);     { Attempt to start padding at sentence break }
  114.  
  115.         if (x = 0) or (x =len) then       { no period or period is at length }
  116.  
  117.           x := 1;                                    { so start at beginning }
  118.  
  119.         if pos(space,jstr) <> 0 then repeat        { ensure at least 1 space }
  120.  
  121.           if jstr[x] = space then                      { so add a soft space }
  122.  
  123.             insert(softSpace,jstr,x+1);
  124.           x := succ(x mod len);  { if eoln is reached return and do it again }
  125.  
  126.         until len = max;        { until the wanted string length is achieved }
  127.  
  128.       end; { if not ... }
  129.       JustifiedStr := jstr;
  130.     end; { JustifiedStr }
  131.  
  132.  
  133.   begin  { Wrap }
  134.     if len <= maxlen then begin                       { no wrapping required }
  135.  
  136.       Wrap := st;
  137.       len  := 0;
  138.     end else begin
  139.       oldlen := len;                { save the length of the original string }
  140.  
  141.       len    := succ(maxlen);                        { set length to maximum }
  142.  
  143.       repeat                     { find last space in st before or at maxlen }
  144.  
  145.         dec(len);
  146.       until (st[len] = space) or (len = 0);
  147.       if len = 0 then                   { no spaces in st, so chop at maxlen }
  148.  
  149.         len := maxlen;
  150.       if justify then
  151.         Wrap := JustifiedStr(st,maxlen)
  152.       else
  153.         Wrap := st;
  154.       newlen :=  len;          { save the length of the newly wrapped string }
  155.  
  156.       len := oldlen;              { and restore it to original length before }
  157.  
  158.       Delete(st,1,newlen);              { getting rid of the wrapped portion }
  159.  
  160.     end;
  161.   end; { Wrap }
  162.  
  163. begin
  164.   S :=
  165. 'By far the easiest way to manage a database is to create an '+
  166. 'index file. An index file can take many forms and its size will depend '+
  167. 'upon how many records you want in the db. The routines that follow '+
  168. 'assume no more than 32760 records.';
  169.  
  170. while length(S) <> 0 do
  171.   writeln(Wrap(S,60,true));
  172. end.
  173.  
  174. Whilst this is tested and known to work on the example string, no further
  175. testing than that has been done.  I suggest you test it a great deal more
  176. before being satisfied that it is OK.  
  177.  
  178. TeeCee
  179.  
  180.  
  181. --- TC-ED   v2.01  
  182.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  183.  * Tossed by SFToss/286 v1.02a on 92/11/24  09:38:09
  184.  
  185. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  186.  
  187. Conference 4
  188. Date       11-23-92 12:56:21
  189. From       Trevor Carlsen
  190. To         Dave Jarvis
  191. Subject    Checking file types
  192.  
  193.  
  194.  
  195.  DJ> USES DOS;
  196.  DJ> VAR
  197.  DJ>   DirInfo : SearchRec;
  198.  DJ>   Ext     : STRING[3];
  199.  DJ> Begin
  200.  DJ>   FindFirst( '*.*', AnyFile, DirInfo );
  201.  DJ>   WHILE DOSError = 0 DO
  202.  DJ>   Begin
  203.  DJ>     IF (DirInfo.Attr AND Directory) <> Directory THEN
  204.  DJ>     Begin
  205.  DJ>       Ext := UpCase( DirInfo.Name[10] ) + UpCase( DirInfo.Name[11] ) +
  206.  
  207.  DJ>              UpCase( DirInfo.Name[12] );
  208.  
  209. The above statement assumes that the extension is always the 10..12th character
  210. of the name string.  That is not so.  It also unnecessarily converts to uppercas
  211. . The name string returned by FindFirst/Next is always uppercase and needs
  212. no conversion.
  213.  
  214. Change the declaration of ext to  string[4] and then replace with
  215.    with DirInfo do
  216.      if pos('.',name) <> 0 then
  217.        ext := copy(name,pos('.',name),4)
  218.      else { no extension }
  219.        ext := ' '; { to prevent nul string }
  220.  
  221. Perhaps better still may be to use the FSplit procedure.
  222.        
  223.  DJ>       IF (Pos( 'COM', Ext ) = 0) AND (Pos( 'EXE', Ext ) = 0) AND
  224.  DJ>          (Pos( 'OBJ', Ext ) = 0) THEN
  225.  
  226. for the above statement it is better to -
  227.   if not (pos(ext,'.COM.EXE.OBJ') = 0) then
  228.  
  229.  DJ>         PrintFile( DirInfo.Name );
  230.  DJ>     End;
  231.  DJ>     FindNext( DirInfo );
  232.  DJ>   End;
  233.  DJ> END.
  234.  
  235.  
  236. --- TC-ED   v2.01  
  237.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  238.  * Tossed by SFToss/286 v1.02a on 92/11/24  09:38:09
  239.  
  240. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  241.  
  242. Conference 4
  243. Date       11-23-92 15:50:53
  244. From       Trevor Carlsen
  245. To         Charles Lindsay
  246. Subject    Speed
  247.  
  248.  
  249.  
  250.  CL> Does anybody know how to make Turbo Pascal find the speed of
  251.  CL> a computer! Also, is there a program to find the speed that
  252.  CL> a modem is connected at.  I got the file BPS_RATE, but It
  253.  CL> tell's what speed the Port is Opened up at.  I need
  254.  CL> something that will tell what Baud it is connected at
  255.  CL> without looking at the CONNECT STRING?
  256.  
  257. Have a little deeper think about that!  
  258.  
  259. What you are asking for is a method of determining some information about
  260. a peripheral not connected to the computer in any way except by the serial
  261. port. But you are not interested in the speed of that interface, only the
  262. speed of the interface beyond the peripheral which has previously advised
  263. that speed via its CONNECT string. 
  264.  
  265. Obviously the only way you can get that information is by interogating the
  266. peripheral. To my knowledge there is no standard modem command that will result
  267. in the modem resending that information.  The Telebit TrailBlazer can be request
  268. d to provide this information via the ATI command.  Other modens may have
  269. similar commands available.
  270.  
  271. However the whole question is really beyond the scope of on-topic discussion
  272.  in this echo although I note you were asking for a TP way - so the short
  273. answer is no.  Better that you ask in a technical echo.
  274.  
  275. As far as determining the speed of your computer, there may be others that
  276. will give you a definitive answer. It will almost certainly involve assembler
  277. rather than TP (in fact I am sure of that!).
  278.  
  279. TeeCee
  280.  
  281.  
  282. --- TC-ED   v2.01  
  283.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  284.  * Tossed by SFToss/286 v1.02a on 92/11/24  09:38:09
  285.  
  286. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  287.  
  288. Conference 4
  289. Date       11-23-92 23:28:54
  290. From       Trevor Carlsen
  291. To         Colin Jones
  292. Subject    TURBO C++
  293.  
  294.  
  295.  
  296.  CJ> I just got Turbo C++(Borland) and I have only had experience
  297.  CJ> in GWBasic...which makes it kind of dificult to
  298.  CJ> understand...if anyone has knowlage about C++
  299.  
  300. Not real clever - asking this question in the Pascal echo.  Try the C echo
  301. and you may do better re informed answers.
  302.  
  303. TeeCee
  304.  
  305. --- TC-ED   v2.01  
  306.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  307.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:04
  308.  
  309. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  310.  
  311. Conference 4
  312. Date       11-23-92 23:42:37
  313. From       Trevor Carlsen
  314. To         Rich Paul
  315. Subject    Reset and ReWrite TP6.0 Style?
  316.  
  317.  
  318.  
  319.  RP> I was using typed files, and tried to rewrite one, (which
  320.  RP> should be read/write access), read a record from it,
  321.  RP> increment a field on the record, and write it back.
  322.  
  323.  RP> It trunciated my file to 0 characters.  ... I don't think
  324.  RP> ANSI Pascal operates like that, and it doesn't mention it in
  325.  RP> the TP docs.
  326.  
  327. That is standard Pascal behaviour and is fundamental to the language.  The
  328. TP docs clearly define the behaviour on p119 under the "ReWrite" procedure
  329. when it says -
  330.   "Creates and opens a new file...
  331.    ...if an external file with same name already exists, it is deleted and
  332. a new empty file is created in its place."
  333.  
  334. That, to me, would be fairly clear.
  335.  
  336. If you want to open an existing file for read/write access use reset if it
  337. is a typed or untyped file. Text files cannot be opened in that mode.
  338.  
  339. TeeCee
  340.  
  341. TeeCee
  342.  
  343. --- TC-ED   v2.01  
  344.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  345.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:04
  346.  
  347. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  348.  
  349. Conference 4
  350. Date       11-23-92 10:45:58
  351. From       Mark Ouellet
  352. To         David Szkilnyk
  353. Subject    Re: DIALOGS NO FRAMES
  354.  
  355.  
  356.     On 04-Nov-92, you, David Szkilnyk, of 3:634/387.0 wrote...
  357.  
  358.  DS> Is it possible to open a dialog box without a frame. I thought if the
  359.  DS> options where set so it didn't include a frame it would not activate
  360.  DS> it but that doesn't make sense if in the constructor init's its
  361.  DS> descendants thus activating the twindow.frame
  362.  
  363. David,
  364.     TDialog.init calls Twindow.init first. By the time you set Options
  365. not to create a frame, Twindow.init has allready inserted it into the
  366. window's group.
  367.  
  368. I believe your only solution would be to create your own Dialog object.
  369.  
  370.  
  371.         Best regards,
  372.         Mark Ouellet.
  373.  
  374.  
  375.  
  376.  
  377. --- Squish v1.01
  378.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  379.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  380.  
  381. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  382.  
  383. Conference 4
  384. Date       11-23-92 10:54:31
  385. From       Mark Ouellet
  386. To         David Webb
  387. Subject    Re: OverView of New TP/BP 7
  388.  
  389.  
  390.     On 18-Nov-92, you, David Webb, of 3:640/943.0 wrote...
  391.  
  392.  DW> Sorry to but in here but are you saying that you can pick up Borland
  393.  DW> Pascal 7.0 with Objects on a CD ROM instead of normal media ?
  394.  
  395. David,
  396.     Yes and it can even run from the CD-ROM!!!! You have a couple of
  397. options. You can either install it from the CD-ROM to your hard-disk or
  398. you can run it directly from the CD-ROM in which case you again have a
  399. couple more choices.
  400.  
  401.     One of them is to have only configuration files such as TURBO.DSK (I
  402. guess) written to your hard-disk. Another options lets you install only
  403. time-critical files to your hard-disk, accessing the rest directly on
  404. the CD-ROM.
  405.  
  406. Richard Nelson mentionned this a few days ago.
  407.  
  408.         Best regards,
  409.         Mark Ouellet.
  410.  
  411.  
  412.  
  413.  
  414. --- Squish v1.01
  415.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  416.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  417.  
  418. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  419.  
  420. Conference 4
  421. Date       11-23-92 11:02:36
  422. From       Mark Ouellet
  423. To         Richard Morris
  424. Subject    Re: BORLAND PARADOX ENGINE
  425.  
  426.  
  427.     On 16-Nov-92, you, Richard Morris, of 3:634/387.0 wrote...
  428.  
  429.  RM> ..... I like being able to query my apps datbase with
  430.  RM> Paradox/Object Vision/Quattro, but then what do you expect from
  431.  RM> someone working at Borland
  432.  
  433. Richard,
  434.     I take it then that you are working for Borland Canada?!! Could you
  435. do me a favor then, could you manage to have information sent to me
  436. about ALL current Borland products. I really mean everything, screen
  437. blankers, programming tools etc...
  438.  
  439.     I need those info as I can never find a complete list of Borland
  440. products. Even my friend who is in the business doesn't have it all nor
  441. do his suppliers.
  442.  
  443. I would specialy like info about the new products available like,
  444. sourcerer's apprentice, Screenery, Brief editor etc...
  445.  
  446.     I receive some but it's allways the same stuff or almost. Last one I
  447. received was for Quattro-Pro for Windows. I own Quattro-Pro but never
  448. actually bought it. It was sent to me by error when I ordered my TP 6.0
  449. PRO and I was told to keep it as a gift. To be honest, in the close to
  450. two years I have had it, I never installed it for more than a few days.
  451. I like it, prefer it over Lotus mind you but I just don't have use for
  452. it right now.
  453.  
  454. Anyways, send me anything you can find to:
  455.  
  456.     Mark Ouellet
  457.     1940 Sheppard Street
  458.     Sillery,
  459.     Province of Quebec, Canada
  460.     G1S 1L2
  461.  
  462.     Phone: (418) 527-6669
  463.  
  464.     I'd really appreciate this 'cause I keep seing stuff like Screenery
  465. at Borland shows, keep hearing about how they aquired the rights to
  466. Brief and Sorcerer's apprentice but never actually got a price for it or
  467. even received offers for them.
  468.  
  469.     BTW, I saw a message about the CD-ROM for BP 7.0. Am I correct, I
  470. think what they said was that I could ADD the CD-ROM for only $19 more
  471. and the CD-ROM contains Bug lists and patches OR WAS THAT that you could
  472. get the bug lists and patches added to the CD-ROM for $19??? (Those are
  473. probably US prices!!)
  474.  
  475.         Best regards,
  476.         Mark Ouellet.
  477.  
  478.  
  479.  
  480.  
  481. --- Squish v1.01
  482.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  483.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  484.  
  485. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  486.  
  487. Conference 4
  488. Date       11-23-92 11:39:12
  489. From       Mark Ouellet
  490. To         Tom Lawrence
  491. Subject    Re: Name
  492.  
  493.  
  494.     On 19-Nov-92, you, Tom Lawrence, of 1:153/401.0 wrote...
  495.  
  496.  >> PROGRAM Display_Name;
  497.  
  498.  >> VAR A,B: INTEGER;
  499.     ^^^^^^^^^^^^^^^^^
  500.  >> BEGIN
  501.  >>    WriteLn ('Enter your name mortal: ');
  502.  >>    ReadLn (A);
  503.        ^^^^^^^^^^^
  504.  
  505.  TL> Yes, but you might have your WRITEs and WRITELNs confused.  The
  506.  TL> program would produce output as follows:
  507.  TL> 
  508.  TL> Enter your name mortal: Tom Lawrence How many times to display your
  509.  TL> name mortal? 2 Tom LawrenceTom Lawrence
  510.  
  511. Say Tom,
  512.     is "Tom Lawrence" a positive or a negative integer?? ;-)
  513.  
  514.         Best regards,
  515.         Mark Ouellet.
  516.  
  517.  
  518.  
  519.  
  520. --- Squish v1.01
  521.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  522.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  523.  
  524. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  525.  
  526. Conference 4
  527. Date       11-23-92 14:29:15
  528. From       Mark Ouellet
  529. To         Alex Boisvert
  530. Subject    Re: Contest
  531.  
  532.  
  533.     On 20-Nov-92, you, Alex Boisvert, of 1:257/405.0 wrote...
  534.  
  535.  AB> Hi Mark - I'll be competing against you... so watch closely on your
  536.  AB> program's optimization ;-)
  537.  AB> 
  538.  AB> Alex. PS:  I haven't submitted my code to Trevor... still making it
  539.  AB> better everyday
  540.  
  541. No problems Alex,
  542.     I had completed one version but started on the next version. Right
  543. now I'm waiting for BP 7.0 to come in and working on some other project
  544. in the mean time.
  545.  
  546.         Best regards,
  547.         Mark Ouellet.
  548.  
  549.  
  550.  
  551.  
  552. --- Squish v1.01
  553.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  554.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  555.  
  556. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  557.  
  558. Conference 4
  559. Date       11-23-92 14:30:53
  560. From       Mark Ouellet
  561. To         Trevor Carlsen
  562. Subject    Re: Contest
  563.  
  564.  
  565.     On 20-Nov-92, you, Trevor Carlsen, of 3:690/644.0 wrote...
  566.  
  567.  TC> You're wrong again!
  568.  
  569. That's what I said ;-)
  570.  
  571.  TC> My program (.EXE only and PKLited with the commercial version) will
  572.  TC> be released Nov 30. You can test run it then. Entries will not be
  573.  TC> released in any form, binary or source, until after the closing date.
  574.  TC> 
  575.  TC> I do not have any entries as yet and doubt that I will until sometime
  576.  TC> in December :-)  I have had many indications of intent, both by
  577.  TC> netmail and here in the echo.
  578.  
  579. Well Trevor,
  580.     good enough, since your program will be the real contender anyways!!
  581. BTW, from what I heard, BP 7.0 uses that 16Meg adress space mostly as
  582. heap!! How are you going to deal with that?? You said no EMS or XMS but
  583. that heap was allowed, do you intend to limit heap space on your machine
  584. by some mean??
  585.  
  586.         Best regards,
  587.         Mark Ouellet.
  588.  
  589.  
  590.  
  591.  
  592. --- Squish v1.01
  593.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  594.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  595.  
  596. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  597.  
  598. Conference 4
  599. Date       11-23-92 14:40:06
  600. From       Mark Ouellet
  601. To         Tony Wouters
  602. Subject    Re: deskjet 500C
  603.  
  604.  
  605.     On 18-Nov-92, you, Tony Wouters, of 2:291/711.1 wrote...
  606.  
  607.  TW> Hi there,
  608.  TW> 
  609.  TW> Is there someone who can tell me how I can put colored ASCII text to
  610.  TW> a DESKJET 500C ?
  611.  TW> 
  612.  TW> It's nice to have a color printer, but not when it doesn't give you
  613.  TW> what you want......
  614.  
  615. Tony,
  616.     If you get an answer to this one I'd like to know ;-) I normally use
  617. windows as it is the only environement so far that gives me access to
  618. the full potential of my 500C (BTW, Windows drivers version 3.0 for the
  619. Deskjet 500C are out).
  620.  
  621.     I don't know about you but I'm deceived of HP's manuals for this
  622. printer. The laser jet manuals gave good example on how to program for
  623. the laserjets. With these manuals you don't even get examples of
  624. black&White programming, let alone color!!
  625.  
  626.         Best regards,
  627.         Mark Ouellet.
  628.  
  629.  
  630.  
  631.  
  632. --- Squish v1.01
  633.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  634.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  635.  
  636. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  637.  
  638. Conference 4
  639. Date       11-23-92 14:51:07
  640. From       Mark Ouellet
  641. To         Rick Schaefer
  642. Subject    Re: Name
  643.  
  644.  
  645.     On 19-Nov-92, you, Rick Schaefer, of 1:231/430.0 wrote...
  646.  
  647.  AC>> Will the above program work?
  648.  
  649.  RS> Nope.  A is defined as an Integer and  you cannot use a readln to get
  650.  RS> an integer.  It only returns a string.
  651.  
  652. Rick,
  653. Out of ten you get 5 points for trying and 0 for the answer ;-).
  654.  
  655. Readln will read integers or any other string, char or ordinal types.
  656.  
  657.         Best regards,
  658.         Mark Ouellet.
  659.  
  660.  
  661.  
  662.  
  663. --- Squish v1.01
  664.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  665.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  666.  
  667. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  668.  
  669. Conference 4
  670. Date       11-23-92 15:05:11
  671. From       Mark Ouellet
  672. To         Trevor Carlsen
  673. Subject    Re: Speed wanted !
  674.  
  675.  
  676.     On 20-Nov-92, you, Trevor Carlsen, of 3:690/644.0 wrote...
  677.  
  678.  TL>> >PD> (variable "svar" is a array[1..400] of string[160])
  679.  TL>> > Firstly, svar cannot be a variable defined as you describe above.  
  680.  
  681.  
  682.  TL>>     Wrong!  If you take the time to multiply it out
  683.  
  684.  TC> Believe it or not I did!  Anyway I plead guilty...brain fade.
  685.  
  686. Hummm.... 400 * 161 > 65519... 0..99 * 100 = 1,000,000... seems like
  687. this contest is going to be a cinch after all ;-)
  688.  
  689.         Best regards,
  690.         Mark Ouellet.
  691.  
  692.  
  693.  
  694.  
  695. --- Squish v1.01
  696.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  697.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  698.  
  699. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  700.  
  701. Conference 4
  702. Date       11-23-92 15:08:31
  703. From       Mark Ouellet
  704. To         Trevor Carlsen
  705. Subject    Re: Contest
  706.  
  707.  
  708.     On 20-Nov-92, you, Trevor Carlsen, of 3:690/644.0 wrote...
  709.  
  710.  TC> My program (.EXE only and PKLited with the commercial version) will
  711.  TC> be released Nov 30.
  712.  
  713. Trevor,
  714.     I forgot to ask, it will be posted in PDNPASCAL??? As you might
  715. remember I have problems getting stuff to/from zone 3!!
  716.  
  717.         Best regards,
  718.         Mark Ouellet.
  719.  
  720.  
  721.  
  722.  
  723. --- Squish v1.01
  724.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  725.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:12
  726.  
  727. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  728.  
  729. Conference 4
  730. Date       11-23-92 08:11:32
  731. From       Dj Murdoch
  732. To         J J Marquez
  733. Subject    Re: Borland Pascal 7.0
  734.  
  735.   JJ> If you only had 28 
  736.  JJ> Meg FREE, you couldn't install it all. 
  737.  
  738. I think you could do the installation manually.  It would be tedious, but
  739. the files are all described.
  740.  
  741. The reason you need the extra space is because some of the files are too big
  742. to fit on a single floppy (even when compressed); they're copied to the hard
  743. disk and joined together there before being uncompressed.  If you did all
  744. of those first, you'd never need more than 28 megs.
  745.  
  746. Of course, buying a 28 meg compiler and having no space left to compile things
  747. wouldn't be the best way to spend your money.
  748.  
  749. --- Msg V3.2
  750.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  751.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:38
  752.  
  753. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  754.  
  755. Conference 4
  756. Date       11-23-92 08:16:52
  757. From       Dj Murdoch
  758. To         Trevor Carlsen
  759. Subject    Re: Array of Pointers
  760.  
  761.   TC> Done as I suggested it would not be a problem.  
  762.  
  763.  TC> BTW my estimate of an array of pointers method taking up 
  764.  TC> almost as much as 50% extra memory would be way off the 
  765.  TC> mark.  Assuming you are using TP6 every string[8] 
  766.  TC> allocated would take 20 bytes - 16 for the string and 4 
  767.  TC> for the pointer. Makes an array of pointers even less 
  768.  TC> attractive in this case.
  769.  
  770. But in reality, you shouldn't use an array of pointers to String[8] - you
  771. should use an array of pointers to String, and use NewStr to allocate them.
  772.  Only those that are fully 8 chars long will waste 20 bytes of space; if they
  773. happen to be empty, they'll only take 4 bytes, and anything with a length
  774. from 1 to 7 will take up 12 bytes.  
  775.  
  776. Depending on the application, it might not take much more space than the array
  777. of String[8], and could take less.  
  778.  
  779. One advantage:  if every now and then you have one that's 100 bytes long,
  780. it won't cause any trouble.   If people who wrote message editors used NewStr,
  781. we wouldn't have all these brain damaged programs that truncate subject lines
  782. to 30 or 40 characters :-).
  783.  
  784. The only disadvantage of NewStr is that you need a function to get the string
  785. value out of the heap, since using a Nil pointer isn't pretty.
  786.  
  787.  
  788. --- Msg V3.2
  789.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  790.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:38
  791.  
  792. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  793.  
  794. Conference 4
  795. Date       11-23-92 08:27:28
  796. From       Dj Murdoch
  797. To         Charles Strusz @ 970/201
  798. Subject    Re: Desperate...
  799.  
  800.   CS> We know who wrote it.  We have only hearsay evidence, 
  801.  CS> however.  I believe that I once heard that many compilers 
  802.  CS> insert the serial number of the version used in the .com files.
  803.  
  804.  CS> Is this a fact?  Is it possible to view this serial 
  805.  CS> number, and who is qualified to be a paid professional 
  806.  CS> expert on such an issue?
  807.  
  808. The best you can do is to determine which brand and version number of compiler
  809. was used.  No compiler that I've ever heard of will put a string identifying
  810. the user into the output.  To find the compiler version, just search through
  811. the executable for a copyright string.  That works on most of them. 
  812.  
  813. As for finding a paid professional expert, you might want to ask for advice
  814. at a local PC users group. If the damage done is a serious loss of data, don't
  815. use the machine again, but find a good data recovery company.  They may also
  816. be willing to testify on your behalf on what they found.
  817.  
  818.  
  819. --- Msg V3.2
  820.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  821.  * Tossed by SFToss/286 v1.02a on 92/11/25  08:06:38
  822.  
  823. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  824.  
  825. Conference 4
  826. Date       11-25-92 11:49:01
  827. From       Trevor Carlsen
  828. To         Kelly Small
  829. Subject    Array of Pointers
  830.  
  831.  
  832.  
  833.  TC> ...Assuming you are using TP6 ev string[8] allocated would
  834.  TC> take 20 bytes - 16 for the string and 4 for the
  835.  
  836.  KS> Why 16 bytes instead of 9 for the string?
  837.  
  838. Because it is being allocated on the heap.  
  839.  
  840. TP6 reintroduced a heap granularity of 8 as compared to TP4/5x's granularity
  841. of one.  I say "reintroduced" because in reality it was returning to the old
  842. TP3 method of heap management by so doing.
  843.  
  844. A granularity of 8 means that memory is always allocated in multiples of 8
  845. bytes, hence a 9 byte variable such as string[8] would have 16 bytes allocated
  846. for it thus wasting 7 bytes.
  847.  
  848. You might be tempted to think that this was a step backwards, however as with
  849. most programming design decisions, it represents a compromise. If every byte
  850. counts it is not so good, but if heap fragmentation is a problem it is a big
  851. improvement.  I take the view that it was a good step as one can always implemen
  852.  their own heap management technique if the need is there for it.
  853.  
  854. TeeCee
  855.  
  856. --- TC-ED   v2.01  
  857.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  858.  * Tossed by SFToss/286 v1.02a on 92/11/26  10:21:44
  859.  
  860. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  861.  
  862. Conference 4
  863. Date       11-25-92 12:01:58
  864. From       Trevor Carlsen
  865. To         Aaron Marasco
  866. Subject    Hiding the cursor
  867.  
  868.  
  869.  
  870.  AM>  MC> --- FMail 0.92  
  871.  AM>  MC> * Origin: Don't let the wave drown you (1:2410/339)  
  872.  AM>   
  873.  AM> Could you repost these for me? It'll be greatly appreciated!  
  874.  
  875. Code is not to be reposted just because you missed it. Arrange for the private
  876. exchange of the code (on YOUR dollar) by netmail.
  877.  
  878. Also please do not quote entire messages including origin and tear lines.
  879. Have some consideration for those paying the bills.
  880.  
  881. If you wish to reply to this message do so by NETMAIL ONLY.
  882.  
  883. Moderator.
  884.  
  885. --- TC-ED   v2.01  
  886.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  887.  * Tossed by SFToss/286 v1.02a on 92/11/26  10:21:44
  888.  
  889. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  890.  
  891. Conference 4
  892. Date       11-25-92 12:10:31
  893. From       Trevor Carlsen
  894. To         Dave Jarvis
  895. Subject    replace a record
  896.  
  897.  
  898.  
  899.  DJ> Actually, in Pascal, as far as I know with records, there
  900.  DJ> isn't a really easy way to replace a record, even after
  901.  DJ> appention.
  902.  
  903. If you are referring to standard Pascal then you are correct. With Turbo Pascal
  904. it is totally incorrect. Even Pascals that claim to be virtually standard
  905. implementations (such as VAX) have the means to read and write to individual
  906. records as a language enhancement. Its called random access. 
  907.  
  908. Look up seek, read, write, reset, BlockRead, BlockWrite in your documentation.
  909.  
  910. TeeCee
  911.  
  912. --- TC-ED   v2.01  
  913.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  914.  * Tossed by SFToss/286 v1.02a on 92/11/26  10:21:44
  915.  
  916. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  917.  
  918. Conference 4
  919. Date       11-25-92 12:18:28
  920. From       Trevor Carlsen
  921. To         Gregory P. Smith
  922. Subject    Reset and ReWrite TP6.0 Style?
  923.  
  924.  
  925.  
  926.  GS> (After you open it for append you can use Seek to get back
  927.  GS> into the middle of the file I believe).
  928.  
  929. Seek cannot be used on text files.  Append can only be used on text files.
  930.  
  931. TeeCee
  932.  
  933. --- TC-ED   v2.01  
  934.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  935.  * Tossed by SFToss/286 v1.02a on 92/11/26  10:21:44
  936.  
  937. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  938.  
  939. Conference 4
  940. Date       11-25-92 19:49:19
  941. From       Trevor Carlsen
  942. To         Sean Ocker
  943. Subject    strings
  944.  
  945.  
  946.  
  947.  SO> What is the 4th character of the third line of text
  948.  SO> in a text file?
  949.  
  950. If you read the line  into a string variable called st then the 4th character
  951. in that line is st[4].
  952.  
  953.  SO> or: Please reverse this string: TODAY
  954.  SO> output should be YADOT
  955.  
  956. var 
  957.   st,
  958.   RevStr : string;
  959.  
  960. st    := 'TODAY';
  961. for x := length(st) downto 0 do
  962.   RevStr[length(st)-x] := st[x];
  963.  
  964.  SO> I need to know how to setup ANYTHING for a string.  How to
  965.  SO> take a number and both use it as a number for calculations
  966.  SO> and a string for string manipulation.
  967.  
  968. To convert a string to a number look up Val in your manual.
  969. To convert a number to a string look up Str in your manual.
  970.  
  971. TeeCee
  972.  
  973. --- TC-ED   v2.01  
  974.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  975.  * Tossed by SFToss/286 v1.02a on 92/11/26  10:21:44
  976.  
  977. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  978.  
  979. Conference 4
  980. Date       11-25-92 00:00:00
  981. From       Terry Hughes
  982. To         Wayel Alwohaibi @ 925/60
  983. Subject    *PRO upgrades
  984.  
  985.  
  986. WA>TH>If you want to use OPRO in protected mode programs and you're not on the
  987.  
  988. WA>TH>Fast Update Plan you'll need to purchase an update for $49. If you
  989.  
  990. WA>        I thought the protected mode implementation was left up to the
  991. WA>PM compiler, i.e. if it runs in real mode it will run in PM when
  992. WA>compiled under PM, no?  If not, what sort of differences do you have to
  993. WA>do in writing PM code?
  994.  
  995. Here are a few of the things that come to mind (from porting APRO and
  996. OPRO):
  997.  
  998. References to real memory addresses (like BiosTics : ^LongInt;
  999. absolute $40:$6C; or Mem[X:X]) must be changed to use selectors that the
  1000. RTL provides or that you provide.
  1001.  
  1002. References to real addresses returned by DOS or BIOS function calls,
  1003. obtained from the PSP or DOS MCB chain must be done through selectors
  1004. that you allocate and manage.
  1005.  
  1006. Usage of segment registers in BASM or external assembly language
  1007. routines must be limited to valid selectors (i.e., can't use segment
  1008. registers as general purpose registers).
  1009.  
  1010. These are the easy ones. Where it gets a bit difficult is understanding
  1011. what different DPMI servers will do for different function calls. In
  1012. many cases you can't depend on all DPMI servers to virtualize the
  1013. same functions the same way. So, you end up needing to call the DPMI
  1014. server yourself to simulate some real mode interrupts. And the only way
  1015. to figure out what you need is by testing these functions under the
  1016. various DPMI servers.
  1017.  
  1018. Other issues include your treatment of heap (much bigger), EMS and XMS
  1019. (now superfluous), overlays (now unnecessary), exec swapping, TSRs and
  1020. so on. All of these things either require different treatment or are no
  1021. longer the best way of doing things under protected mode.
  1022.  
  1023. And of course, there's always the "latent bug exposure". There were some
  1024. things you could always get away with in real mode that you can't get
  1025. away with in pmode. For example, under real mode it was always safe to
  1026. dereference a pointer immediately after disposing it (poor programming,
  1027. but it would always work). Under protected mode this will generate a
  1028. GPF.
  1029.  
  1030. Obviously, many of these low-level issues affect us, as library vendors,
  1031. worse then they affect an applications programmer. We spent a lot of
  1032. time converting and testing our libraries under various DPMI servers so,
  1033. hopefully, you won't have to deal with too many of these issues
  1034. yourself.
  1035.  
  1036.  -Terry
  1037. ___
  1038.  X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-9726)
  1039.  
  1040. --- Maximus 2.01wb
  1041.  * Origin: The Programmers Playhouse (1:128/60)
  1042.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:03
  1043.  
  1044. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1045.  
  1046. Conference 4
  1047. Date       11-26-92 06:03:34
  1048. From       Trevor Carlsen
  1049. To         Frank Masingill
  1050. Subject    TP7??
  1051.  
  1052.  
  1053.  
  1054.  FM> ...More importantly, I'd value your opinion about whether I
  1055.  FM> should now upgrade to BP 7.0. ...A good many others at my
  1056.  FM> level might value your opinion on this (or at least some
  1057.  FM> comments pro and con) if you care to give them.
  1058.  
  1059. As I have not yet received my copy (Oz is low on the Borland priority scale),
  1060. I'll delay any comment.  I noticed today that another Oz user has his TP7
  1061. so I guess that RSN I may have mine.
  1062.  
  1063. TeeCee
  1064.  
  1065. --- TC-ED   v2.01  
  1066.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1067.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:10
  1068.  
  1069. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1070.  
  1071. Conference 4
  1072. Date       11-26-92 06:28:42
  1073. From       Trevor Carlsen
  1074. To         Mark Ouellet
  1075. Subject    Re: Contest
  1076.  
  1077.  
  1078.  
  1079.  MO> BTW, from what I heard, BP 7.0 uses that 16Meg adress space
  1080.  MO> mostly as heap!! How are you going to deal with that?? You
  1081.  MO> said no EMS or XMS but that heap was allowed, do you intend
  1082.  MO> to limit heap space on your machine by some mean??
  1083.  
  1084. No. 
  1085.  
  1086. disqualified := not ProgramRunsOKon8088XT;
  1087.  
  1088. TeeCee
  1089.  
  1090. --- TC-ED   v2.01  
  1091.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1092.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:10
  1093.  
  1094. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1095.  
  1096. Conference 4
  1097. Date       11-26-92 06:36:26
  1098. From       Trevor Carlsen
  1099. To         Sean Ocker
  1100. Subject    strings
  1101.  
  1102.  
  1103.  
  1104.  SO> or: Please reverse this string: TODAY
  1105.  SO> output should be YADOT
  1106.  
  1107. My previous example was wrong and I'm sure that about 1000 messages pointing
  1108. out that I was in error in my hasty example to you on the above are about
  1109. to issue into the net! :-(
  1110.  
  1111. Here is a workable way -
  1112.  
  1113.   function ReverseStr(st: string): string
  1114.     var x : byte;
  1115.     begin
  1116.       ReverseStr[0] := st[0];
  1117.       for x := length(st) downto 1 do
  1118.         ReverseStr[succ(length(st) - x)] := st[x];
  1119.     end;
  1120.  
  1121. TeeCee
  1122.  
  1123.  
  1124. --- TC-ED   v2.01  
  1125.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1126.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:10
  1127.  
  1128. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1129.  
  1130. Conference 4
  1131. Date       11-26-92 06:44:20
  1132. From       Trevor Carlsen
  1133. To         Chet Kress
  1134. Subject    Print-Screen Disable!
  1135.  
  1136.  
  1137.  
  1138.  CK> Does anyone have any code to disable the Print-Screen
  1139.  CK> Key?...I would appreciate two procedures with some inline
  1140.  CK> code.  One to disable the print-screen key and the other to
  1141.  CK> re-enable it again...
  1142.  
  1143. No inline as requested as it is unnnecessary but the following should work.
  1144.  
  1145.  
  1146. uses dos;
  1147.  
  1148. var
  1149.   OldInt5 : pointer;
  1150.  
  1151. procedure NewInt5; interrupt; far;
  1152.   begin 
  1153.     { deliberately empty procedure }
  1154.   end;
  1155.  
  1156. procedure DisableInt5;
  1157.   begin
  1158.     GetIntVec($05,OldInt5);
  1159.     SetIntVec($05,@NewInt5);
  1160.   end;
  1161.  
  1162. procedure EnableInt5;
  1163.   begin
  1164.     SetIntVec($05,OldInt5);
  1165.   end;
  1166.  
  1167. TeeCee
  1168.  
  1169.  
  1170. --- TC-ED   v2.01  
  1171.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1172.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:10
  1173.  
  1174. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1175.  
  1176. Conference 4
  1177. Date       11-26-92 07:46:02
  1178. From       Trevor Carlsen
  1179. To         Stewart Bird
  1180. Subject    findfirst help
  1181.  
  1182.  
  1183.  
  1184.  SB> I have been trying to do a tree program and I want to
  1185.  SB> isolate the directories, from ordinary files. I can exchange
  1186.  SB> the varible 'anyfile' with 'directory' and I still get the
  1187.  SB> same results. If I have a directory of files, and
  1188.  SB> subdirectories, it prints them all. What is the sense of
  1189.  SB> having the 'anyfile or directory' varible. I guess I could
  1190.  SB> use the getfattr procedure, but that varible must have a
  1191.  SB> reason, and I'm missing it.}
  1192.  
  1193. The FindFirst/FindNext procedures returns details of any file that has the
  1194. specified bit set in the attribute byte PLUS any normal file.  So if you specify
  1195. the directory attribute, all directories will be listed PLUS all normal files. 
  1196.  
  1197.  
  1198. This means that you have to test after each call to see if the directory bit
  1199. is set or not. Do this by -
  1200.   if (DirInfo.attr and Directory) = Directory then 
  1201.      It is a directory
  1202.  
  1203. TeeCee
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209. --- TC-ED   v2.01  
  1210.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1211.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:10
  1212.  
  1213. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1214.  
  1215. Conference 4
  1216. Date       11-26-92 07:47:18
  1217. From       Trevor Carlsen
  1218. To         Peter Beeftink
  1219. Subject    findfirst help
  1220.  
  1221.  
  1222.  
  1223.  PB> You can use the variable Dirinfo.attr to weed out
  1224.  PB> directories. Directories have Dirinfo.attr=16.
  1225.  
  1226. Whilst that may correct some of the time, it will not be correct all of the
  1227. time.  
  1228.  
  1229. A directory will always have bit 4 set of the attribute byte. There is nothing
  1230. that says other bits cannot also be set so if you test in that way some director
  1231. es may be overlooked.
  1232.  
  1233. Better is
  1234.   if (DirInfo.attr and Directory) = Directory then
  1235.     You can be sure that you have not missed any directory.
  1236.  
  1237. TeeCee
  1238.  
  1239. --- TC-ED   v2.01  
  1240.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1241.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:10
  1242.  
  1243. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1244.  
  1245. Conference 4
  1246. Date       11-26-92 07:49:05
  1247. From       Trevor Carlsen
  1248. To         Bob Swart
  1249. Subject    MAKESTR (for contest)
  1250.  
  1251.  
  1252.  
  1253.  BS> What I meant was: can the strings contain OTHER
  1254.  BS> characters than 'a'..'z' and 'A'..'Z'
  1255.  
  1256. No
  1257.  
  1258. function MakeRndStr: string;
  1259.   var x : byte;
  1260.       t : string;
  1261.       sa: array[0..255] of byte absolute t;
  1262.       l : byte absolute t;
  1263.   begin
  1264.     l := 3 + random(28);
  1265.     for x := 1 to l do
  1266.       sa[x] := 65 + random(26) + (random(2) shl 5);
  1267.     MakeRndStr := t;
  1268.   end;
  1269.  
  1270.  BS> Did any contenders already enter the contest? 
  1271.  
  1272. No
  1273.  
  1274.  BS> ... How can we get your benchmark? (UUENCODED ??)
  1275.  
  1276. It will be placed in PDN.
  1277.  
  1278. TeeCee
  1279.  
  1280.  
  1281.  
  1282. --- TC-ED   v2.01  
  1283.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1284.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:10
  1285.  
  1286. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1287.  
  1288. Conference 4
  1289. Date       11-24-92 07:56:55
  1290. From       Dj Murdoch
  1291. To         Jakob Paikin
  1292. Subject    Re: Borland Pascal
  1293.  
  1294.   DM> Not quite complete - the overlay manager and the 
  1295.  JP> coprocessor emulator are
  1296.  DM> supplied in .OBJ form.
  1297.  
  1298.  JP> Thats true - but understandable... Borland don't want us 
  1299.  JP> to know their internal goodies :-)
  1300.  
  1301. No, not really understandable.  A run-time library is all internal goodies,
  1302. isn't it?  
  1303.  
  1304. There are two problems with having these parts missing.  First, the coprocessor
  1305. emulator in TP 6 was buggy - it wasn't really safe to use for serious calculatio
  1306. s.  I don't know if these bugs were fixed or not.  Second, I'd like to remove
  1307. some of the limitations of the emulator and the overlay manager, but it's
  1308. much harder without having the source code.  For example, the overlay manager
  1309. still can't cache overlays in XMS memory.  That would be really easy to add,
  1310. but it's not really safe to do low level work with an undocumented interface.  
  1311.  
  1312.  
  1313. I suspect the reason these parts are missing is that they weren't written
  1314. at Borland.  Borland licensed them from someone, and didn't buy the right
  1315. to distribute them in source code.
  1316.  
  1317. --- Msg V3.2
  1318.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1319.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:19
  1320.  
  1321. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1322.  
  1323. Conference 4
  1324. Date       11-24-92 08:09:38
  1325. From       Dj Murdoch
  1326. To         Jakob Paikin
  1327. Subject    Re: Second bug in TP7/BP7 :-)
  1328.  
  1329.   JP> Just found the following change from TP6 to BP7:
  1330.  
  1331.  JP> In TP6 Pos('',S) returned 1 (That is: The empty string was 
  1332.  JP> contained in everystring).
  1333.  
  1334.  JP> In BP7 Pos('',S) returns 0 (That is: The empty string is 
  1335.  JP> NOT contained in any string).
  1336.  
  1337. In fact, the two releases of TP 6 were inconsistent about this.  BP7 agrees
  1338. with TP 6.01.
  1339.  
  1340. I find it hard to call either of these a bug:  it doesn't make sense to search
  1341. for an empty string, and the manual's definition of Pos doesn't define how
  1342. it should behave in this case.  I'd say it's an error on your part to call
  1343. Pos with an empty string.
  1344.  
  1345. --- Msg V3.2
  1346.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1347.  * Tossed by SFToss/286 v1.02a on 92/11/27  23:23:19
  1348.  
  1349. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1350.  
  1351. Conference 4
  1352. Date       11-25-92 08:17:36
  1353. From       Dj Murdoch
  1354. To         David Webb
  1355. Subject    Re: TP7
  1356.  
  1357.   DW>    I must admit that I'm not too happy with Borland for 
  1358.  DW> not announcing the release of their BP7.0 product earlier, 
  1359.  DW> especially when I, only just over a month ago, purchased 
  1360.  DW> an upgrade from TP5.5 to TP6.0. 
  1361.  
  1362. I don't know the Australian policy (nor do I speak for Borland), but in North
  1363. America you'd get the TP7 upgrade for free.  I've heard conflicting reports
  1364. about whether you get the BP7 upgrade at a better price or not.
  1365.  
  1366.  
  1367. --- Msg V3.2
  1368.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  1369.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:04:37
  1370.  
  1371. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1372.  
  1373. Conference 4
  1374. Date       11-25-92 01:30:50
  1375. From       Mark Ouellet
  1376. To         Trevor Carlsen
  1377. Subject    Re: Checking file types
  1378.  
  1379.  
  1380.     On 22-Nov-92, you, Trevor Carlsen, of 3:690/644.0 wrote...
  1381.  
  1382. Trevor,
  1383. I knew you loved Pascal but.... ;-)
  1384.  
  1385.  TC> No there is not.  Try this (untested)...
  1386.  TC> function PrintableFile(fname: PathStr): boolean;
  1387.  TC> var
  1388.  TC>    dir   : DirStr;
  1389.  TC>    name  : NameStr;
  1390.  TC>    ext   : ExtStr;
  1391.  TC> begin
  1392.  TC>    FSplit(fname,dir,name,ext);
  1393.  TC>    if ext[0] <> #0 then
  1394.  TC>        PrintableFile := (pos(ext,'.OBJ.COM.EXE') = 0);
  1395.                                            ^^             ^
  1396.                                            ^              No ";" allowed
  1397.                                            ^              before an
  1398.                                            ^              else.
  1399.                                            ^
  1400.                                            ^ Program will flag "C"
  1401.                                            source files as not printable
  1402.                                            files.
  1403.  
  1404.  TC>    else
  1405.  TC>        PrintableFile := true;
  1406.  TC> end;
  1407.  
  1408.  
  1409.         Best regards,
  1410.         Mark Ouellet.
  1411.  
  1412.  
  1413. --- Squish v1.01
  1414.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1415.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:07
  1416.  
  1417. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1418.  
  1419. Conference 4
  1420. Date       11-26-92 07:51:19
  1421. From       Mark Ouellet
  1422. To         Adam Kolodziejczak
  1423. Subject    Re: Borland Pascal
  1424.  
  1425.  
  1426.     On 21-Nov-92, you, Adam Kolodziejczak, of 1:153/763.0 wrote...
  1427.  
  1428.  AK> If you guys want 32 bit instructions now, why not study a bit of ASM?
  1429.  AK> I studied it, and the speed is AWESOME... it includes all instructions
  1430.  AK> from the 86 to the 486 to the 487... it is real neat. And you just
  1431.  AK> include the code to speed up the critical parts of the program.
  1432.  
  1433. Sure Adam,
  1434.     we can allways code the time critical stuff in assembler but I
  1435. really can't wait for the day when a compiler produces better code than
  1436. hand coded and optimized assembler. Then, we'll really be able to say
  1437. "There's an optimizing compiler!!"
  1438.  
  1439.     Everybody prefers a high level language because it's easier to code.
  1440. Even Assembler fanatics can't honestly say they wouldn't prefer it!! I
  1441. call those who do liars, after all, why do they use MACRO assemblers
  1442. then, if not to make the task simpler. Isn't their idea of using
  1443. Macro-Assemblers and Macro libraries aimed towards that goal.
  1444.  
  1445.     I believe when Compilers produce that good a code, we'll probably
  1446. see a lot less assembler fanatics.
  1447.  
  1448.     From that aspect, a Borland Pascal that will produce 32bit code, not
  1449. only math operations, will be wellcomed by everyone. I heard they were
  1450. working on a 32bit version, I sure hope we can see it for BP 7.5 or 8.0
  1451.  
  1452.         Best regards,
  1453.         Mark Ouellet.
  1454.  
  1455.  
  1456.  
  1457.  
  1458. --- Squish v1.01
  1459.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1460.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:07
  1461.  
  1462. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1463.  
  1464. Conference 4
  1465. Date       11-26-92 07:59:47
  1466. From       Mark Ouellet
  1467. To         Colin Jones
  1468. Subject    Re: TURBO C++
  1469.  
  1470.  
  1471.     On 21-Nov-92, you, Colin Jones, of 1:153/734.0 wrote...
  1472.  
  1473.  CJ> I just got Turbo C++(Borland) and I have only had experience in
  1474.  CJ> GWBasic...which makes it kind of dificult to understand...if anyone
  1475.  CJ> has knowlage about C++ or knows which are the best books to
  1476.  CJ> buy...could you leave me a message...Thanks Colin Jones
  1477.  
  1478. Colin,
  1479.     If you left your message in a C++ echo instead of a Pascal echo
  1480. you'd stand a better chance of getting an answer. C++ is OFF-TOPIC here,
  1481. but there is a C++ echo available on Fidonet. Ask your sysop if he has
  1482. it or if he can get it for you.
  1483.  
  1484.         Best regards,
  1485.         Mark Ouellet.
  1486.  
  1487.  
  1488.  
  1489.  
  1490. --- Squish v1.01
  1491.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1492.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:07
  1493.  
  1494. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1495.  
  1496. Conference 4
  1497. Date       11-26-92 08:09:26
  1498. From       Mark Ouellet
  1499. To         Mike Copeland
  1500. Subject    Re: Array of Pointers
  1501.  
  1502.  
  1503.     On 21-Nov-92, you, Mike Copeland, of 1:114/18.10 wrote...
  1504.  
  1505.  MC> const LIM  = 10000; type STR8  = string[8]; DPTR  = array[1..LIM] of
  1506.  MC> ^STR8; var  KELLY : DPTR;
  1507.  MC> 
  1508.  MC> begin New (KELLY);  { acquire data space } KELLY^[1] := 'Mikey';
  1509.  MC> or....
  1510.  MC> var  KELLY : array[1..LIM] of ^STR8; I     : Word;
  1511.  MC> begin for I := 1 to LIM do New (KELLY[I]); KELLY[1]^ := 'Mikey';
  1512.  MC> 
  1513.  
  1514. Mike,
  1515.     Actually, it's not one or the other!! Only your second example is
  1516. correct. Kelly is an Array of pointers, not a pointer to an Array, so
  1517. "new(Kelly)" is incorrect.
  1518.  
  1519.         Best regards,
  1520.         Mark Ouellet.
  1521.  
  1522.  
  1523.  
  1524.  
  1525. --- Squish v1.01
  1526.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1527.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1528.  
  1529. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1530.  
  1531. Conference 4
  1532. Date       11-26-92 08:12:38
  1533. From       Mark Ouellet
  1534. To         Mike Copeland
  1535. Subject    Re: Smart Linking (???)
  1536.  
  1537.  
  1538.     On 22-Nov-92, you, Mike Copeland, of 1:114/18.10 wrote...
  1539.  
  1540.  MC> I have often answered queries here about the benefits and uses of TP
  1541.  MC> Smart Linking - but I have uncovered a real problem! Using a global
  1542.  MC> data Unit, which has (previously) contained hundreds of variables used
  1543.  MC> by many different programs - under a single Var declaration...things
  1544.  MC> were fine.  Then, I decided to "optimize" my system a bit, by taking
  1545.  MC> better advantage of S/L.  I went through this Unit, and I inserted a
  1546.  MC> "Var" in front of every variable in this large global list of
  1547.  MC> variables - and my main program (the one I wanted to get most benefit)
  1548.  MC> grew 14K!!! Nothing else done to the program!  (It _should_ have had
  1549.  MC> the opposite effect, right?) Note that the .EXE grew about 700 bytes -
  1550.  
  1551.  MC> but the Data represented on the .MAP file grew 14K.... Any thoughts?
  1552.  
  1553. Mike,
  1554.     Have you tried turning Debug info OFF. It seems to me the increase
  1555. in size of the .MAP is normal as MORE SYMBOLS are now created since each
  1556. variable is now a seperate block. The increase in the .EXE is probably
  1557. caused by this too. If you TDSTRIP it you will probably find that it is
  1558. not any larger than before. All those 700 bytes are is the info for
  1559. those variables now generating more symbols. The difference from 14K to
  1560. 700 bytes is that the .MAP contains ALL the symbols from ALL Units,
  1561. program files etc... while the .EXE debug info only contains symbols
  1562. that were actually included by the linker.
  1563.  
  1564.     Please try it and tell me if I hit the spot, as I wanted to start
  1565. taking advantage of Smart/linking myself and don't think it will affect
  1566. the end result size-wise. But if you prove me wrong, then....
  1567.  
  1568.         Best regards,
  1569.         Mark Ouellet.
  1570.  
  1571.  
  1572. --- Squish v1.01
  1573.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1574.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1575.  
  1576. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1577.  
  1578. Conference 4
  1579. Date       11-26-92 08:25:33
  1580. From       Mark Ouellet
  1581. To         Jeff Cook @ 970/1
  1582. Subject    Re: Borland Pascal?
  1583.  
  1584.  
  1585.     On 16-Nov-92, you, Jeff Cook @ 970/1, of 1:10/8.0 wrote...
  1586.  
  1587.  JC> I have TP 6.0... where is 7.0 out and what is this Borland Pascal....
  1588.  JC> where do they sell it.... ooops maybe I'd know if I had sent in my
  1589.  JC> registration form.... ahh well!
  1590.  
  1591. Jeff,
  1592.     Yes Turbo Pascal 7.0 is out. But there is now a name-change in
  1593. effect. They now use the same naming conventions they introduced with
  1594. Borland C++ if you know about that.
  1595.  
  1596.     Basically it's like this:
  1597.  
  1598.     1-  There is no PRO version anymore, or rather it's not called that
  1599.         anymore.
  1600.  
  1601.     2-  It's Now called "Borland Pascal with Objects 7.0" and the other
  1602.         one is "Turbo Pascal 7.0" or maybe "Turbo Pascal with Objects
  1603.         7.0", I'm not sure about that one as I got the BP 7.0 version.
  1604.  
  1605. BTW, From here on, I'll refer to "Borland Pascal with Objects 7.0" as
  1606. BPWO and "Turbo Pascal 7.0" as TP7.
  1607.  
  1608.     3-  BPWO includes Assembler, Debugger, Profiler and a full line of
  1609.         Windows tools as well as Windows version of the Debugger etc...
  1610.         You can think of this one as the new "PRO" version. This one
  1611.         includes everything but it's huge.
  1612.  
  1613.     4-  TP7 does not contain Assembler or Debugger etc... This is the
  1614.         small version and can not compile to anything BUT DOS.
  1615.  
  1616.     5- BPWO can now compile for
  1617.             DOS real mode
  1618.             DOS protected mode
  1619.             Windows
  1620.  
  1621.     6-  BPWO includes, 5 different versions of the compiler:
  1622.  
  1623.             #1  BP.exe runs in DOS Protected mode. Requires 286 or
  1624.                 better. Can compile for DOS, DOS protected or windows.
  1625.                 This one is an IDE (ie: Integrated Devellopement
  1626.                 Environement, Long term to mean, Interractive Editor,
  1627.                 Debugger etc...)
  1628.  
  1629.             #2  BPW.exe same as BP.exe except this one runs under
  1630.                 windows.
  1631.  
  1632.             #3  Turbo.exe, IDE, runs in DOS real mode compiles for DOS
  1633.                 real mode only. (This one is said to still run on XT I
  1634.                 think)
  1635.  
  1636.             #4  BPC.exe command-line version of the Protected mode
  1637.                 compiler. (ie: same functionnalaty as BP.exe except not
  1638.                 an IDE)
  1639.  
  1640.             #5  TPC.exe command-line version of Turbo.exe.
  1641.  
  1642.  
  1643.     7-  BPWO also include FULL SOURCE to Turbo Vision, Runtime Library
  1644.         and Object Windows library (OWL)
  1645.  
  1646.     8-  BPWO will use 32bit Math instructions if it detects a 386 or 486
  1647.         for optimized math operation.
  1648.  
  1649.     9-  Both products, ie TP7 & BPWO's IDEs now have Syntax Color
  1650.         Highlighting. So you wont get anymore errors from comments you
  1651.         forgot to close, because now you will instantly notice that your
  1652.         code has taken the color or comments !!!!
  1653.  
  1654. Note that BPWO is huge if you install everything but, I have never seen
  1655. an Install program with so much options. You can literally specify very
  1656. precisely WHAT you want installed. Which makes it easy to limit the
  1657. necessary disk space.
  1658.  
  1659. BTW, TP7 and BPWO now support Null-terminated strings like "C". Which
  1660. means you can now have strings 64K in size.
  1661.  
  1662. I have only had it for a few hours, BPWO that is, and I'm allready in
  1663. love with it. It's great, even the ONLINE-HELP can now include YOUR OWN
  1664. HELP. Yes!!! You can now compile your own help to include it with the
  1665. online help system. This means you can compile Turbo Power's help files
  1666. to include them ONLINE or any other help file you normally need while
  1667. programming and have it available inside turbo. That also means that
  1668. Turbo's HELP Hot-Key (CTRL-F1) will bring you help of YOUR functions,
  1669. not only Borland's. Note that some help files might need a little work
  1670. to be included and work correctly but it can NOW be done. I don't know
  1671. about you but I definitly prefer a "It can be done with work" than a "No
  1672. it can't be done at all".
  1673.  
  1674. Almost forgot, Turbo vision is now upgraded to Version 2.0 with this
  1675. release and the manual is 1 inch think just for Turbo Vision. It also
  1676. has new functions added or changed.
  1677.  
  1678.         Best regards,
  1679.         Mark Ouellet.
  1680.  
  1681.  
  1682. --- Squish v1.01
  1683.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1684.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1685.  
  1686. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1687.  
  1688. Conference 4
  1689. Date       11-26-92 08:57:54
  1690. From       Mark Ouellet
  1691. To         Jeff Cook @ 970/1
  1692. Subject    Re: Borland Pascal?
  1693.  
  1694.  
  1695.     On 16-Nov-92, you, Jeff Cook @ 970/1, of 1:10/8.0 wrote...
  1696.  
  1697.  JC> I have TP 6.0... where is 7.0 out and what is this Borland Pascal....
  1698.  JC> where do they sell it.... ooops maybe I'd know if I had sent in my
  1699.  JC> registration form.... ahh well!
  1700.  
  1701. OOPS, sorry Jeff,
  1702.     I forgot... You can order your upgrade directly from Borland. But if
  1703. you are a student I suggest you mention it to see if there is a special
  1704. pricing available to you. You will probably have to buy it through your
  1705. School in that case though. Also, I think the Educationnal program only
  1706. refers to TP7, not BPWO. It makes sens, after if you are a student then
  1707. BPWO is really seen as the Professionnal programmer's version.
  1708.  
  1709. Anyways, if you need to call Borland to upgrade then the number is:
  1710.  
  1711.     for the USA:  1-800-331-0877, extension 5017
  1712.  
  1713.     for Canada:   1-800-461-3327
  1714.  
  1715.         Best regards,
  1716.         Mark Ouellet.
  1717.  
  1718.  
  1719.  
  1720.  
  1721. --- Squish v1.01
  1722.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1723.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1724.  
  1725. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1726.  
  1727. Conference 4
  1728. Date       11-26-92 09:04:26
  1729. From       Mark Ouellet
  1730. To         Paul West
  1731. Subject    Re: OverView of New TP/BP 7
  1732.  
  1733.  
  1734.     On 21-Nov-92, you, Paul West, of 1:343/27.0 wrote...
  1735.  
  1736.  PW> Yes!  Thats how I have ordered it (Assuming it ever arrives).
  1737.  
  1738. Paul,
  1739.     I recieved my BPWO 7.0 yesterday. I ordered it on normal media but
  1740. I'm in Canada. US residents have been posting here for a few days saying
  1741. they had received their version but Borland Canada was not yet shipping
  1742. yet when I last called last week. So if the fact I received mine is any
  1743. indication, I'd say yours is probably on it's way right now. Unless they
  1744. have more delays for CD-ROMs. Borland, as many other software
  1745. manufacturers, deal with third parties for disks & CD-ROM duplications
  1746. as well as Manual printing.
  1747.  
  1748.         Best regards,
  1749.         Mark Ouellet.
  1750.  
  1751.  
  1752.  
  1753.  
  1754. --- Squish v1.01
  1755.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1756.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1757.  
  1758. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1759.  
  1760. Conference 4
  1761. Date       11-26-92 09:10:42
  1762. From       Mark Ouellet
  1763. To         Stephen Carpenter
  1764. Subject    Re: Turbo Vision menus
  1765.  
  1766.  
  1767.     On 22-Nov-92, you, Stephen Carpenter, of 1:343/27.0 wrote...
  1768.  
  1769.  SC> Hi Y'all I am writing a turbo vision program in which I would like the
  1770.  SC> menubar to change when certian options are chosen from the first
  1771.  SC> menubar.  I have done something basically like this:
  1772.  
  1773.  SC> this doesn't seem to work.  What does?
  1774.  
  1775. Stephen,
  1776.     I suggest you take a look at Neil J. Rubenking's "Turbo Pascal 6.0
  1777. Techniques and Utilities". It's published by Ziff Davis (you know,
  1778. PC-Magazine?!) ISBN number is 1-56276-010-6, price is 39.95 $US, 49.95
  1779. $Can or 36.95 pounds for the U.K.
  1780.  
  1781.     In there Neil shows exactly how to do this. His example is that of a
  1782. Multi-Lingual menu. The user can chose between French, English or
  1783. Spanish menus.
  1784.  
  1785.     You should really give this book a look, unless you prefer to wait
  1786. 'till he gets a Turbo Pascal 7.0 version out. In any case this book
  1787. contains many other nice tricks. It's one of the really good TP books
  1788. around.
  1789.  
  1790.         Best regards,
  1791.         Mark Ouellet.
  1792.  
  1793.  
  1794. --- Squish v1.01
  1795.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1796.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1797.  
  1798. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1799.  
  1800. Conference 4
  1801. Date       11-26-92 09:18:13
  1802. From       Mark Ouellet
  1803. To         Kelly Small
  1804. Subject    Re: Array of Pointers
  1805.  
  1806.  
  1807.     On 22-Nov-92, you, Kelly Small, of 1:114/36.0 wrote...
  1808.  
  1809.  KS> In a message to KELLY SMALL, MIKE COPELAND says:
  1810.  KS> 
  1811.  MC>>   const LIM  = 10000;
  1812.  MC>>   type STR8  = string[8];
  1813.  MC>>        DPTR  = array[1..LIM] of ^STR8;
  1814.  MC>>   var  KELLY : DPTR;
  1815.  MC>>
  1816.  MC>> begin
  1817.  MC>>   New (KELLY);  { acquire data space }
  1818.  MC>>   KELLY^[1] := 'Mikey';
  1819.  
  1820.  KS> This first method didn't compile but is similar to what I tried to do.
  1821.  KS> 'kelly' isn't a pointer type and won't work with New.  If I change the
  1822.  KS> var declaration to 'kelly : ^dptr' then it will compile but won't
  1823.  KS> allocate the correct amount of heap space.  The 2nd method with the
  1824.  KS> For loop will allocate the string space on the heap, but I wonder if
  1825.  KS> there's a way for the first method to do so?
  1826.  
  1827. Kelly,
  1828. Yes you can, by combining the two methods like this:
  1829.  
  1830.    Make Kelly a Pointer to DPTR like you said but remember you now have
  1831.    to new BOTH times like this:
  1832.  
  1833.    Kelly : ^Dptr;
  1834.  
  1835.     New(Kelly); {Allocate space on the heap for the array itself}
  1836.         { This way it won't waste valuable space in your data segment}
  1837.  
  1838.     for x := 1 to LIM do {Alloc space for each string}
  1839.         new(Kelly^[x]);
  1840.  
  1841.     And refer to them this way:
  1842.  
  1843.     Kelly^[ 10 ]^ := 'Mickey';
  1844.  
  1845.     Remember:
  1846.  
  1847.         Kelly           is the adress of our array.
  1848.  
  1849.         Kelly^          is the array itself.
  1850.  
  1851.         Kelly^[ 10 ]    is the 10th adress in our array.
  1852.  
  1853.         Kelly^[ 10 ]^   is the string pointed to by the tenth adress in
  1854.                         our array.
  1855.  
  1856.         Best regards,
  1857.         Mark Ouellet.
  1858.  
  1859.  
  1860. --- Squish v1.01
  1861.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1862.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1863.  
  1864. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1865.  
  1866. Conference 4
  1867. Date       11-26-92 09:38:42
  1868. From       Mark Ouellet
  1869. To         Joseph Tomaras
  1870. Subject    Re: my program
  1871.  
  1872.  
  1873.     On 21-Nov-92, you, Joseph Tomaras, of 1:3609/9.0 wrote...
  1874.  
  1875.  JT> procedure addnum(var num:number;num1,num2:number);
  1876.  JT> var rep,carov:shortint;
  1877.  JT> begin
  1878.  JT> for rep:=100 downto 1 do
  1879.  JT> begin
  1880.  JT> num[rep]:=num1[rep]+num2[rep]+carov;
  1881.  JT> carov:=0;
  1882.  
  1883.     One problem I see here Joseph, is that you didn't initialise carov
  1884. before the loop so it's value is UNDEFINED on the first pass through the
  1885. loop. Which means it can have any value, basically it will have the
  1886. value of what ever was in memory before the compiler put carov there.
  1887.  
  1888.     Same problem in StrechFold, NUM1 is not initialised before you call
  1889. negnum with it.
  1890.  
  1891.         Best regards,
  1892.         Mark Ouellet.
  1893.  
  1894.  
  1895.  
  1896.  
  1897. --- Squish v1.01
  1898.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1899.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1900.  
  1901. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1902.  
  1903. Conference 4
  1904. Date       11-26-92 09:47:36
  1905. From       Mark Ouellet
  1906. To         Rob Addie
  1907. Subject    Re: High-speed modems
  1908.  
  1909.  
  1910.     On 22-Nov-92, you, Rob Addie, of 1:140/81.0 wrote...
  1911.  
  1912.  RA> I have been away from Pascal for a number of months now, and I have hit 
  1913.  
  1914.  RA> the  same stumbling block that I did before I put Pascal aside.  I am 
  1915.  
  1916.  RA> having  trouble with my modem routines that USED to work perfect at 2400 
  1917.  
  1918.  RA> baud.  But  now, I have a 9600 v32 modem, and my once perfect routines 
  1919.  
  1920.  RA> are not up to  snuff.  I have absolutely no documentation for locked 
  1921.  
  1922.  RA> baud rates (how to lock  them and how to unlock them).  Has there been a 
  1923.  
  1924.  RA> revision to the FOSSIL  standard?  Or where might I find something that 
  1925.  
  1926.  RA> would help me out?  If it  really is a simple concept, I'd appreciate 
  1927.  
  1928.  RA> some help here in this echo.  I  really need help!
  1929.  
  1930. Rob,
  1931.     Basically in NON-LOCKED mode, the modem simply outputs that connect
  1932. speed as the last thing before changing speed itself to match that of
  1933. the remote modem. That is because it expects you to change the comm port
  1934. speed to match that of the remote and of your own modem because it is
  1935. also now running at that speed and needs to be accessed at that speed.
  1936.  
  1937.     I'd say, running LOCKED-baud is a lot easier... Basically you ignore
  1938. the connect speed message because your modem will also ignore it and
  1939. continue to run at the same speed between you and it. It will however
  1940. change the speed it uses between itself and the remote but that is
  1941. transparent to you.
  1942.  
  1943.     So basically in LOCKED-BAUD, you really have nothing more to do
  1944. except handle the extra speed your 9600 is now giving you. In fact you
  1945. do less because now you don't have to bother about changing the comm
  1946. port's speed to match that of your modem.
  1947.  
  1948.     If your routines can allready handle 19200 or 38400, which is
  1949. probably one of the speeds you locked your modem at, then you have
  1950. nothing to worry about. If however you problem IS that you can't handle
  1951. 19200 or 38400 then there are async libraries available in shareware as
  1952. well as commercial ones like Turbo Power's.
  1953.  
  1954.         Best regards,
  1955.         Mark Ouellet.
  1956.  
  1957.  
  1958.  
  1959.  
  1960. --- Squish v1.01
  1961.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1962.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1963.  
  1964. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1965.  
  1966. Conference 4
  1967. Date       11-26-92 10:05:43
  1968. From       Mark Ouellet
  1969. To         Anthony Vivona
  1970. Subject    Re: question
  1971.  
  1972.  
  1973.     On 21-Nov-92, you, Anthony Vivona, of 1:107/236.0 wrote...
  1974.  
  1975.  AV> To everyone,
  1976.  AV> Does anybody know how to run a dos program from within my 
  1977.  AV> pascal  program ??
  1978.  
  1979. Anthony,
  1980.     Check out the "EXEC" procedure in your manual.
  1981.  
  1982.         Best regards,
  1983.         Mark Ouellet.
  1984.  
  1985.  
  1986.  
  1987.  
  1988. --- Squish v1.01
  1989.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  1990.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  1991.  
  1992. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1993.  
  1994. Conference 4
  1995. Date       11-26-92 10:09:50
  1996. From       Mark Ouellet
  1997. To         Robert Jambor
  1998. Subject    Re: Speed wanted !
  1999.  
  2000.  
  2001.     On 19-Nov-92, you, Robert Jambor, of 3:640/521.64 wrote...
  2002.  
  2003.  RJ> 65520 being the largest data structure allowed.
  2004.  
  2005. Robert,
  2006.     Actually, 64K or 65536 bytes or array [0..65535] of byte IS the
  2007. largest allowed.
  2008.  
  2009.     65520 is the largest data structure SAFE to use. The reason is that
  2010. offsets will vary from 0 to F in normalized pointers. And since you
  2011. can't be sure that your structure will be created at offset 0 then any
  2012. value above 65520 bytes risks wrap-around when you try to access the
  2013. last elements.
  2014.  
  2015.         Best regards,
  2016.         Mark Ouellet.
  2017.  
  2018.  
  2019.  
  2020.  
  2021. --- Squish v1.01
  2022.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  2023.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:08
  2024.  
  2025. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2026.  
  2027. Conference 4
  2028. Date       11-26-92 10:15:21
  2029. From       Mark Ouellet
  2030. To         Trevor Carlsen
  2031. Subject    Re: Array of Pointers
  2032.  
  2033.  
  2034.     On 23-Nov-92, you, Trevor Carlsen, of 3:690/644.0 wrote...
  2035.  
  2036.  TC> BTW my estimate of an array of pointers method taking up almost as much 
  2037.  
  2038.  TC> as 50% extra memory would be way off the mark.  Assuming you are using 
  2039.  
  2040.  TC> TP6 every string[8] allocated would take 20 bytes - 16 for the string 
  2041.  
  2042.  TC> and 4 for the pointer. Makes an array of pointers even less attractive 
  2043.  
  2044.  TC> in this case.
  2045.  
  2046. TeeCee,
  2047.     you meant 13 right?? 9 for the String[8] and 4 for the pointer for a
  2048. total of 13?!!
  2049.  
  2050.         Best regards,
  2051.         Mark Ouellet.
  2052.  
  2053.  
  2054.  
  2055.  
  2056. --- Squish v1.01
  2057.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  2058.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:09
  2059.  
  2060. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2061.  
  2062. Conference 4
  2063. Date       11-26-92 10:20:39
  2064. From       Mark Ouellet
  2065. To         Trevor Carlsen
  2066. Subject    Re: Checking file types
  2067.  
  2068.  
  2069.     On 23-Nov-92, you, Trevor Carlsen, of 3:690/644.0 wrote...
  2070.  
  2071.  DJ>>       IF (Pos( 'COM', Ext ) = 0) AND (Pos( 'EXE', Ext ) = 0) AND
  2072.  DJ>>          (Pos( 'OBJ', Ext ) = 0) THEN
  2073.  
  2074.  TC> for the above statement it is better to -
  2075.  TC> if not (pos(ext,'.COM.EXE.OBJ') = 0) then
  2076.  
  2077. TeeCee
  2078.     you really hate ".C" files that much?? ;-)
  2079.  
  2080.         Best regards,
  2081.         Mark Ouellet.
  2082.  
  2083.  
  2084.  
  2085.  
  2086. --- Squish v1.01
  2087.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  2088.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:09
  2089.  
  2090. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2091.  
  2092. Conference 4
  2093. Date       11-26-92 10:30:06
  2094. From       Mark Ouellet
  2095. To         Dave Jarvis
  2096. Subject    Re: replace a record
  2097.  
  2098.  
  2099.     On 23-Nov-92, you, Dave Jarvis, of 1:249/128.0 wrote...
  2100.  
  2101.  DJ> Actually, in Pascal, as far as I know with records, there isn't a really 
  2102.  
  2103.  DJ> easy way to replace a record, even after appention.
  2104.  DJ> 
  2105.  DJ> The algorythm to replace a record goes something like:
  2106.  DJ> 
  2107.  DJ> 1) Open a temporary file for write (file 2)
  2108.  
  2109. <rest deleted>
  2110.  
  2111. Dave,
  2112.     He's talking of a file of records. With random access files there is
  2113. no need for what you describe. At least not for REPLACING a record with
  2114. some other data. If he wanted to DELETE a record than that would be
  2115. another story. It can be easy or it can be hard, it all depends if you
  2116. need to PHYSICALLY remove the record or just mark it as being deleted.
  2117.  
  2118.     But again, for what he wanted, all he has to do is seek to the
  2119. particular record he wants to replace and write out the new info.
  2120.  
  2121.         Best regards,
  2122.         Mark Ouellet.
  2123.  
  2124.  
  2125.  
  2126.  
  2127. --- Squish v1.01
  2128.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  2129.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:09
  2130.  
  2131. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2132.  
  2133. Conference 4
  2134. Date       11-26-92 10:39:11
  2135. From       Mark Ouellet
  2136. To         Stewart Bird
  2137. Subject    Re: findfirst help
  2138.  
  2139.  
  2140.     On 23-Nov-92, you, Stewart Bird, of 1:247/101.0 wrote...
  2141.  
  2142.  SB> { Can anyone help.
  2143.  SB> I have been trying to do a tree program and I want to
  2144.  SB> isolate the directories, from ordinary files. I can exchange the
  2145.  SB> varible
  2146.  SB> 'anyfile' with 'directory' and I still get the same results. If I have
  2147.  SB> a
  2148.  SB> directory of files, and subdirectories, it prints them all. What is the
  2149.  SB> sense of having the 'anyfile or directory' varible. I guess I could use
  2150.  SB> the getfattr procedure, but that varible must have a reason, and I'm
  2151.  SB> missing it.}
  2152.  
  2153. Stewart,
  2154.     First of all, the Directory and AnyFile bit is not Borland's Fault,
  2155. It's Microsoft's RETARDED way of doing things. Remember Borland's Pascal
  2156. only calls DOS functions $4E (FindFirst), $4F (FindNext). It is DOS's
  2157. stupid way of handling attributes that does that.
  2158.  
  2159. Here is how DOS handles attributes in those calls:
  2160.  
  2161.     If Attributes is 0, DOS returns ALL normal file entries. DOS does
  2162.     not return hidden, system, or subdirectory files.
  2163.  
  2164.     If Attributes is 2, 4, or 16, DOS returns each of those file types,
  2165.     AND ALL DOS normal files.
  2166.  
  2167.     If attribute is 8, DOS ONLY returns the disk volume label.
  2168.  
  2169.  
  2170.         Best regards,
  2171.         Mark Ouellet.
  2172.  
  2173. --- Squish v1.01
  2174.  * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/1.4)
  2175.  * Tossed by SFToss/286 v1.02a on 92/11/28  08:05:09
  2176.